Security-JAWS 第13回レポート #secjaws #secjaws13 #jawsug
Security JAWS 第13回のレポートです。WAFやGuardDutyの話から、運用のツラミまで、いろんな内容がありました！レポートをみて気になった方はDoorkeeperからSecurity-JAWSのコミュニティに登録してください！
こんにちは、臼田です。
Security JAWS 第13回が開催されましたのでレポート致します。
Security JAWS 【第13回】 勉強会 2019年5月24日(金) - Security-JAWS | Doorkeeper
レポート
Session1: アマゾンウェブサービスジャパン株式会社 SaaS Partner Solutions Architect 清水 毅さん 「Amazon GuardDutyを用いた脅威検知と対応」
- 話すこと
- 脅威検知と対応
- 脅威検知サービス
- 脅威対応サービス
- 世間の状況
- ベライゾンから情報漏えい結果のグラフが出ている
- Web Applicationsにおける情報漏えいが頻発している
- AWSとしてもその対策を気にしてほしいと考えている
- 脅威検知と対応
- 脅威検知は難しい
- セキュリティは見なければ行けない範囲が大きい
- 人がどうやって見るのかわからない
- 人がやっていたら精度が上がらない
- 誤検知なのかわからない
- 人材確保も難しい、ビジネス的に開発を優先してセキュリティエンジニアの育成も遅れがち
- AWSからのメッセージ
- 「人をデータから切り離す」
- re:Invent 2017にて言われた
- 人だと間違いが無くならないから
- データ侵害の検知
- 攻撃活動が始まって成功した場合、87%の割合で数分単位で完了している
- 一方それを見つけるまでには68%が1ヶ月以上かかっている
- 数分で見つけたのは3%程度
- 人でやるには限界がある
- AWSセキュリティソリューション
- NISTのサイバーフレームワークをベースに分類
- 検知と対応のサービスを深掘りしていく
- CloudTrailやConfig
- CloudWatch等々
- 脅威検知は難しい
- 脅威検知サービス
- ログデータソース
- AWS CloudTrail
- ユーザの振る舞いやAPIの記録
- VPC Flow Logs
- IP周り
- CloudWatch Logs
- アプリケーションログなど
- 最近はCloudWatch Insightで分析しやすくなっている
- DNS Logs
- Route53ではない
- AWSしかログを見れない
- AWS CloudTrail
- 機械学習
- AWS自身が機械学習を使ったサービスを提供
- Amazon GuardDuty
- AWSアカウントを継続的に監視
- Amazon Macie
- S3に上がってきた機密情報などの文字列を検知
- まだ日本には来ていない
- Amazon GuardDuty
- ボタンワンクリックで有効化するだけ
- エージェントやセンサー等不要
- 価格は安めで、取り込むイベントやログの従量
- 価格の参考: https://dev.classmethod.jp/cloud/aws/guardduty-si-strongest-thread-detection/
- 脅威の種類
- 悪意のあるスキャン
- ポートスキャン
- 総当たり攻撃
- インスタンスへの脅威
- C&Cサーバへの通信
- アウトバウンドDDoS
- アカウントへの脅威
- 不正なAPIの呼び出し
- 予期しないリソースアクセス
- 悪意のあるスキャン
- 自分たちでログを取る必要は必ずしもない
- 始めるのはすごく簡単！
- ただ、何かあった時に辿るために各種ログを取ったほうが良い
- Security Hub
- GuardDutyやInspector、外部のサービスの検知情報をまとめるハブ
- AWS Config Rule
- CloudWatch Event Rule
- それぞれ条件を設定してアクションを実行できる
- ログデータソース
- 脅威対応サービス
- AWS Lambda
- イベント検知をトリガーに自動的に対応するなど
- AWS Systems Manager
- EC2の中の調査など
- Amazon Inspector
- 脆弱性の確認
- それぞれのサービスを連携して検知から対応まで自動化することができる
- GuardDutyからCloudWatch Eventを経由してLambdaで通知したりできる
- AWS Lambda
- ワークショップもやっているのでぜひエントリーしてみてください！
感想
セキュリティの対応は人でやるのは本当に辛いので、ぜひ脅威検知のサービスであるGuardDutyを使っていきたいですね！
とりあえず詳しく知りたいという方はこちらも参照してください！
Session2: 株式会社サイバーセキュリティクラウド CTO 渡辺 洋司さん「AWS WAFを使いこなそう」
[slideshare id=147406477&doc=securityjawsawswaf-190524101154]
- 攻撃遮断くんとWafCharmを運営している
- 実はSecurity JAWS第4回でも登壇していた
- その頃はAWS WAFで正規表現ができなかった
- まず、AWS WAFを理解しよう
- AWSが提供するWAF
- セキュリティベンダーがマネージドルールを提供
- ACLに設定できるルールは10個まで
- 使った分だけ支払い
- ルール構造
- UMLでクラス図書いてみた
- WebACLに複数Ruleがある
- Ruleの中に各種conditionsがある
- conditionsはSQLiとかXSSとかの種類がある
- WebACLをCloudFrontやALB、API Gatewayにアタッチできる
- RulesはRegularとRate Baseがある
- Rate Baseは一定時間のアクセス数に応じて対応
- Regularはそれ以外
- Filters
- IPやGeo、リクエストの中身のエンコードなどの組み合わせ
- ルール動作
- condition内のFilterはOR条件
- Rule内のconditionはAND条件
- RuleがTrueの場合にAction(Allow, Block, Count)実行
- どれにもマッチしなければDefault Action
- マネージドルール
- セキュリティベンダー提供
- 低価格
- すぐ導入できる
- 更新はベンダー任せ
- ルール数が多い場合もある
- AWS WAF使ってみよう
- 実運用を想定したルール設定
- OWASP Top 10のうち一般的な攻撃を防御する
- 問題のあるIPをブラックリストで防御
- などなど
- AWS WAFのチュートリアルからやるといい
- XSS, SQLi等止めてくれる
- CloudFromationのテンプレートから簡単に作れる
- 実運用を想定したルール設定
- 使いこなす
- アプリケーション全体のホワイトリストを設定する
- 特定のIPだけAllowする
- 特定のパスではXSSを検知させない
- ルール10個以上 / 複数のマネージドルールを使いたい
- CloudFront + ALBそれぞれでAWS WAFを使う
- ALB + ReverseProxy(N段)
- 頑張ればできなくはないがレイテンシー等気になる
- アプリケーション全体のホワイトリストを設定する
- おまかせする
- WafCharmというサービスをやっている
- ルールの運用を自動でできる！
- カスタマイズも相談できる！
- ブラックリストIPの運用も自動になる！
- マネージドルールとの連携も可能
- SQLiの誤検知とかがあっても、一律でOffにしないで、足りないルールをカスタマイズして補ったりできる！
感想
AWS WAFは簡単にラフに安く使い始められるWAFサービスなので、これまでWAFを検討してこなかったスケールのサービスにも検討いただけると思います！
このスライドの説明で分かりづらいなーと感じたりしたら、WafCharmとかにおまかせするのもいいと思います！
ちなみにサイバーセキュリティクラウドさんのマネージドルールについてはこちら！
Session3: 株式会社QUICK 小出 淳二さん「エンタープライズのオンプレWAFをAWSに移行したらこうなった話」
- AWS上でのWAF構成
- BIG-IPをALBでサンドイッチ
- BIG-IP4台で負荷分散
- スケールアウトを考えている
- BIG-IP VE ASMアプライアンスを採用
- なんでASMなのか
- 機能要件を満たしている
- 金融エンタープライズは誤検知に対する顧客要求レベルが厳しい
- 誤検知の問い合わせを速やかにピンポイントで対応できることが必須の機能要件
- 実際の画面の紹介
- ドリルダウンで辿れる
- リクエストのBodyが出てくる
- どういう問い合わせなのかすぐに分かる
- クラウド型WAFは高トラフィックだと費用高
- SaaS障害時の運用考慮も必要
- Impervaは自由度が低いので選定外(2017/10時点)
- CFのJSON編集
- 構築後の名前変更不可
- バックエンドのELBはCLBのみ
- 機能要件を満たしている
- ASM設計のポイント
- 2台のMultiAZではなくスケールアウト可能なActive-Active
- VSのアドレスを0.0.0.0としどうきするconfigは全台同じ
- VSのポート番号毎にサービスを割り当てる
- オンプレとは違う
- SNATのアドレスもiRule判定とし動悸するconfigは全台同じ
- SNATポート枯渇問題にも対応
- 最大IP16個の制限を突破
- ASMの構成変更等の影響を極力受けない設計
- インスタンスを作り直したりしても大丈夫なようにALBのバックエンドをIPアドレス指定
- ENIを付け替えて対応
- F5 ASMのいいところ
- きちんと運用すれば最高
- 機能は充実
- 管理画面も良い
- スケールアウト構成が可能
- 12台だけど安定する
- イマイチなところ
- 高い
- BYOLのライセンスも結構する
- マーケットプレイスでもぼちぼちする
- 更にAWS usage
- 設計(サイジング、可用性等)が必要
- お手軽にボタン一つとはいかない
- トラフィックとL7性能を考慮
- ASMのスペックシートは非公開
- Best Bundle 200Mbps 4台とした
- 構成が複雑
- 障害時切り分けが大変
- ソフトウェアEOSDとの戦いが続く
- メモリリークのバグが多かった(昔)
- 世の中にナレッジがない
- BYOL版をパートナーに半強制させられる
- オンデマンドだとサポートできないと言われる
- 結局AWSにいってもオンプレみたい
- 高い
- AWS WAFは使えないの？
- ようやくエンタープライズで使えるレベルに近づいてきた！
- FullログはあるけどBodyが来ていない…
- いい感じのマネージドルール + 誤検知対応でどうにか運用できないか？
- ブラックボックスじゃないマネージドルールがほしい！
- まとめ
- 今後のAWS WAFに期待
感想
アプライアンスWAFのツラミがよくわかりましたね。
アプライアンスWAFはもっと使いやすくなってほしいなって強く感じます。
AWS WAFもこのレベルの置き換えになってくると良いなーと思いますね！使いやすいダッシュボード機能とか、Bodyのロギング期待です！
Session4: Check Point Software Technologies 西田 和弘さん「VPC Flow Log/CloudTrailと連携したセキュリティインテリジェンスMagellanを使ってみた」
- VPC Flow LogsとCloudTrailを分析するのでGuardDutyと似ていると思われるが、目的は近いがアプローチは結構違う
- MagellanはDome9の追加機能としてリリース予定
- オブジェクトマッピングアルゴリズムを用いてログ、イベントを可視化
- GuardDutyと同じようにアラートを上げたりSIEM連携もできます
- メリットは業務の効率化
- Dome9の機能
- 主に静的な情報に対する可視化、コンプライアンスなど
- 構成ステータスの可視化・分析
- Compute
- Netowork
- Storage
- DB
- IAM
- ログ
- 構成ステータスの可視化・分析
- 主に静的な情報に対する可視化、コンプライアンスなど
- Magellanの機能
- 動的な情報に対する可視化、検知SIEM連携
- インベントリとログ、Threat Cloudと組み合わせて分析
- 見てみよう
- 直近のVPC Flow Logsの傾向を見る
- ポートや送信元別の統計グラフを出す
- CloudTrail
- IAMユーザの操作統計を出す
- 少し詳しく見ていく(分析例)
- 送信元を自動的にカテゴライズ(外部、不正IP、AWS内、S3等)
- 不正IPのアイコンを押すと、それからどこにアクセスしているかエンティティー一覧を見れる
- エンティティーも選択するとどのようなやり取りをしているか見やすく表示
- 直近のVPC Flow Logsの傾向を見る
- 使い方はいくつかある
- インシデント対応
- アセットID、IPアドレスから調べていく方法
- 特定のイベント、事象から調べていく方法
- 定常的なイベント検知
- デフォルトのルールセットで異常を監視して通知・アラート
- GuardDutyと違って機械学習はしない
- しかしカスタマイズルールの作成は可能
- 特定のアセットからインシデント調査
- IPを入力すると、関連する通信を図に出すことができる
- そこからドリルダウンできる
- 特定イベントから被害状況を調べる
- 外部から大規模な侵入が発生
- Threat Hunting機能により詳細を調べる
- 外部からのSSHアクセスを調べるクエリを選択
- 図になる
- ドリルダウン
- 標準提供の検索可能なイベントが沢山ある
- インシデント対応
- 定常監視 - デフォルトのルールセット
- 監視ベストプラクティス
- IAM監視
- NW監視
- サーバレス監視
- キー管理の監視
- などなど
- 詳細項目一例
- IAM操作やコンソールアクセス、ルートアクセス系の異常など
- VPC Flow LogsではIP周りやLambdaからのSSHなど
- ポリシーによる通知設定も可能
- アラートでは担当者割り当てをしてチケット管理もできる
- カスタムアラートが簡単に作れる
- GUIベースでクエリを簡単に作れる
感想
ログやイベントを眺めるのは辛いですが、図にマッピングできるのは非常に頼もしいですね！
GuardDutyは機械学習でいい感じにやってくれますが、より自分たちで色々見たり、ハンドリングしたい場合や、トラッキングを行うにはMagellanはうまく使えそうですね！
リリースはこれからとのことなので、期待ですね！
Session5: FiNC Technologies 鈴木 健二さん「マイクロサービスでのセキュリティパッチ含めたライブラリ更新のつらみと取り組み」
- ライブラリをちゃんと更新しましょうという話
- Rails4.0から5.1に上げるとビッグバン
- ちゃんとSmall Releaseしよう
- Small Releaseのほうが良い
- セキュリティの観点から
- 脆弱性はある日突然来る
- 最新数バージョンしかパッチが当たらないこともある
- 常に最新に追いつく運用をしていないと独自のパッチを当て続けることになる
- 依存するパッケージもバージョンを上げる必要があったりする
- セキュリティの観点から
- 結論
- 細かくバージョンを上げましょう
- 問題
- マイクロサービスが40個ぐらいある
- 何が問題なのか？
- 単純計算で40回同じ作業
- 専門のチームを作っても対応が難しい
- サービス間の依存も考える必要がある
- 各チームの意識やスキルのばらつき
- 一つの作業漏れが全体に影響する可能性
- マイクロサービスのツラミでもある
- メリットもある
- 規模が小さいので一つ一つは小さい
- チーム間の情報共有ができる
- 新しいマイクロサービスで先に新しいバージョンを使える
- 系全体としてはカナリアっぽくなる
- 何をすべきか？
- チーム間で情報を横断的にシェアしつつ
- みんなで頑張る
- やってみたこと
- 可視化
- 各アプリケーションのライブラリのバージョンを横断して可視化
- どのアプリがバージョンが低いママ放置されているかを一目瞭然に
- 定例でチェック
- 自動化
- CircleCIでライブラリのアップデートのPull Requestを自動でつくる
- githubユーザはdependabotが無料で利用可能になってのでそちらでもいいかも
- 今後試したい
- 各チームで独立して動けるように
- OSレイヤー以上はDockerfileで管理
- もともとSREチームがDockerfileを管理していた
- 徐々に開発チームにも移譲
- 各チームで独立してアップデートが可能になっている
- 有志での活動
- 週イチで集まって行き届いていないところをサポート
- リリースが立て込んでいたら別チームがフォロー
- 祭り的にやる
- RubyKaigiの裏番組をやったり
- 期の目標に入れる
- クリティカルなものはちゃんと入れる
- 可視化
- 成果も見えてきた
- 主要なアプリケーションは24h以内にほぼ対応完了
- 数日以内に全てのアプリケーションで対応完了
- 今後取り組みたいこと
- SLOへの組み込み
- セキュリティ運用達成度の数値化
- 細かいライブラリを更新し続けられているチームは素晴らしい
- マイクロサービスを新しく作る判断軸としてのセキュリティ達成度
- 逆に、一定レベルで達成できていたらちょっと冒険していい
- セキュリティ運用達成度の数値化
- SLOへの組み込み
- まとめ
- まだまだ課題がある
- 完全に各チームで自走できていない
- しかし自動化すれば余地があると思う
- CIでライブラリ更新 -> ステージング -> カナリアはできそう
- まだまだ課題がある
感想
マイクロサービスになるとよりライブラリの管理は大変になっていることがよくわかりました。
なるべく自動化していくことも必要ですが、人も大切であることが伝わりました！
さいごに
実は初めてChimeで配信しながら開催してみました。配信を見られた方はいかがでしょうか？
資料が公開されない物もあったので、気になる方はDoorkeeperに登録して次のイベントもチェックしてください！
